Known storage operating systems typically contain a program to check and repair an associated file system (e.g., a consistency checker or a file system verification program). In an inode-based file system, files are stored in two pieces: (1) a chunk of data somewhere in the file system; and (2) an inode, which is a data structure containing information about the location, size, creation/modification/access times, ownership, access attributes of, and links to the file. Disk storage is typically implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of storage space. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. Storage of information on the disk array may be implemented as one or more storage “volumes” of physical disks, defining an overall logical arrangement of disk space. The disks within a volume are typically organized as one or more groups, wherein each group may be operated as a Redundant Array of Independent (or Inexpensive) Disks (RAID). Each volume may be associated with its own file system.
A file system verification program may be implemented to operate in two phases: an inode phase and a directory phase. In the inode phase, the file system verification program looks at each buffer tree associated with an inode. A “buffer tree” is a linked list of indirect and direct file data blocks, which, in turn, point to file data blocks on the disks that comprise the file system. The file system verification program moves down each buffer tree and verifies that all pointers are valid and that no cross links occur.
In the directory phase, the file system verification program verifies the directory structure stored within the file system. For example, the checking process may first iterate through all of the file inodes of the file system and then through all of the directories of the file system.
A storage system may implement so called flexible volumes, where the file system layout flexibly allocates an underlying physical volume into one or more virtual volumes of a storage system. To that extent, the sizing of flexible volumes is flexible, which avoids partitioning of storage space and any resulting problems. The underlying physical volume may be an aggregate comprising one or more groups of disks, such as RAID groups.
In a system that supports flexible volumes, each flexible volume may be represented by a file in the aggregate, called a container file, which is hidden and stores all blocks used by the associated flexible volume. The aggregate may also include a hidden metadata directory that contains a list of all flexible volumes in the aggregate in a form of subdirectories, e.g.:                WAFL/uuid/filesystem file                    /storage label file                        
Specifically, a “physical” file system (WAFL) directory includes a subdirectory for each flexible volume in the aggregate, with the name of subdirectory being universal unique identifier (uuid) of the flexible volume. Each uuid subdirectory contains at least two files, a container file and a storage label file. The storage label file is illustratively a 4 kB file that contains metadata similar to that stored in a RAID label. In other words, the storage label file is the analog of a RAID label and, as such, contains information about the state of the flexible volume such as, e.g., the name of the flexible volume, the uuid and file system identifier (fsid) of the flexible volume, whether it is online, being created or being destroyed, etc.
In order for the system to distinguish between non-container files and container files, each container file in the aggregate is associated with a special type of inode (flexible volume type), designating the file as a container file.
Because container files are represented differently from non-container files within a file system and also have associated storage label files, in order for a file system verification program to check and repair a system that supports flexible volumes, the program should be able to recognize and handle container files, as well as the associated storage label files, in an appropriate manner.